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Abstract:  Agile  Command  and  Control  (C2)  requires  agile  information  sharing  with  an 
increasingly  wide  variety  of  military  and  non-military  partners.  While  current  “net-centric” 
approaches  may  improve  information  sharing  within  a  particular  niche  of  C2,  they  do  not  support 
information  sharing  across  the  larger  C2  domain.  Although  not  a  silver  bullet,  the  development 
and  application  of  a  C2  domain  ontology  to  improve  C2  data  and  service  integration  appears  to 
be  increasingly  realistic.  In  fact,  there  are  several  examples  of  successful  ontology  applications 
in  domains  such  as  medicine,  biology,  and  engineering,  and  the  new  discipline  of  Applied 
Ontology  is  emerging.  C2  data,  architecture,  and  conceptual  modeling  activities  which  bear  a 
close  resemblance  to  applied  ontology  activities  are  also  beginning  to  take  shape,  and  there  are 
several  efforts  with  near  to  mid-term  promise  as  elements  of  a  C2  domain  ontology.  This  paper 
provides  an  overview  of  ontology,  examples  of  existing  ontologies,  key  C2  data,  architecture, 
and  modeling  efforts  with  applicability  to  a  C2  domain  ontology,  and  recommendations 
regarding  the  way  ahead.  It  is  the  authors'  conclusion  that  development  of  a  practical  C2  domain 
ontology  is  necessary  and  feasible  in  the  near  to  mid  term,  and  that  efforts  should  commence 
following  the  principles  and  best  practices  of  the  applied  ontology  community. 

Background 

In  May  2003,  the  United  States  (U.S.)  Department  of  Defense  (DoD)  published  the  DoD  Net- 
Centric  Data  Strategy  [1],  which  officially  launched  the  quest  to  transform  DoD  information 
sharing  from  a  producer-centric  to  a  consumer-centric  approach  in  support  of  the  emerging 
concept  of  net-centric  operations  and  warfare.  This  document  was  followed  by  the  North 
Atlantic  Treaty  Organization  (NATO)  Net-Enabled  Capability  (NNEC)  Data  Strategy  [2]  and  the 
DoD  Net-Centric  Services  Strategy  [3],  and  the  same  approach  is  being  adopted  by  many  other 
coalition  and  inter-agency  partners.  Whereas  a  producer-centric  information  sharing  approach  is 
characterized  by  stove-piped  systems,  point-to-point  interfaces,  and  a  “need-to-know” 
information  sharing  philosophy,  a  consumer-centric  information  sharing  approach  is 
characterized  by  open  standards,  many-to-many  interfaces,  and  a  “need-to-share”  information 
sharing  philosophy  where  data  and  services  are  viewed  as  enterprise  assets.  Making  data  and 
services  widely  available  in  this  manner  improves  access  to  information  needed  for  situational 
awareness,  better  enabling  warfighters  at  all  echelons  to  understand  and  adapt  to  changes  in  the 
operational  environment.  This  will  continue  to  be  important  in  the  future  Joint  Operational 
Environment,  where  warfighters  must  innovate  and  adapt  to  counter  a  broad  range  of  threats 
from  often  unpredictable  adversaries.  [4] 

At  the  architecture  and  technology  level,  the  approach  to  implementing  a  net-centric  data  and 
service  strategy  has  been  to  mimic  the  phenomenal  information  sharing  success  of  the  Internet  by 
leveraging  web-based  methods  for  describing  and  sharing  data  and  services  as  well  as  the 
concept  of  Service  Oriented  Architecture  (SOA).  The  extensible  Markup  Language  (XML)  and 
its  associated  family  of  standards  have  become  U.S.  DoD  and  NATO  standards,  the  preferred 
method  for  exposing  and  accessing  data  is  via  web-services,  and  federated  search  methods  for 
searching  defense-related  data  stores  are  being  implemented.  The  concept  of  SOA  has  taken 
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hold  in  key  C2  capability  development  activities  such  as  the  U.S.  Net-Enabled  Command 
Capability  (NECC)  and  NNEC,  and  initial  core  enterprise  services  for  storing,  searching,  and 
retrieving  data,  services,  and  associated  metadata  are  in  place. 

At  the  management  level,  the  approach  to  implementing  a  net-centric  data  and  service  sharing 
strategy  in  the  U.S.  DoD  and  NATO  has  been  to  divide  and  conquer  the  overall  information 
sharing  problem  through  Communities  of  Interest  (COI),  each  focused  on  a  specific  operational 
need.  COIs  are  formed  by  the  relevant  stakeholders  to  address  a  specific  data  sharing  need,  and 
each  COI  is  responsible  for  determining  which  data  is  relevant  and  authoritative  in  the  context  of 
the  COI,  how  to  describe  the  data  in  a  common  format,  and  how  to  make  data  accessible  to  the 
members  of  the  COI  and  the  enterprise  via  web  services.  In  the  parlance  of  the  net-centric  data 
strategy,  the  COI’s  role  is  to  make  its  data  and  web  services  “visible,  accessible,  and 
understandable”. 

While  the  concept  of  using  individual  COIs  to  tackle  subsets  of  the  overall  data  sharing  problem 
was  a  necessary  and  good  first  step,  over  time  it  has  become  clear  that  COIs  operating 
independently  may  not  be  providing  the  information  agility  that  was  initially  expected,  even 
when  individual  COIs  are  successful.  This  is  because  COIs  operating  independently  with  no 
overall  conceptual,  technical,  or  governance  framework  have  resulted  in  multiple  independent 
representations  for  the  same  data,  making  it  very  difficult  to  share  data  and  services  across  COIs. 
Thus,  while  data  and  services  may  be  visible,  accessible  and  understandable  within  each  COI, 
they  are  not  necessarily  understandable  outside  of  the  COI,  nor  interoperable  across  COIs  and 
with  legacy  capabilities  and  standards.  [5]  A  consumer  that  combines  data  and  services  from 
multiple  communities,  a  characteristic  of  many  C2  functions,  must  be  able  to  interpret  multiple 
data  and  service  metadata  artifacts  and  then  mediate  between  them  in  order  to  make  effective  use 
of  the  data  and  services.  This  can  be  quite  difficult  and  time-consuming,  and  is  not  quite  the 
consumer-centric,  agile  approach  to  data  sharing  that  was  envisioned. 

Given  this  reality,  how  can  C2  data  and  services  be  more  understandable  and  interoperable 
across  the  C2  domain?  While  the  use  of  open  standards  such  as  XML  to  describe  and  share  data 
may  get  us  partially  there,  clearly  there  is  much  more  to  be  done.  Specifically,  to  promote  data 
and  service  interoperability  within  the  C2  domain,  there  is  a  need  for  common  message  structure, 
common  semantics,  and  a  common  descriptive  framework  for  C2.  While  data  standardization 
and/or  standard  information  exchange  models  have  been  used  to  support  C2  data  exchange  and 
integration  in  the  past,  this  approach  has  not  proven  successful  and  it  is  clear  that  large  scale 
data  standardization  at  the  physical  level,  even  as  a  data  exchange  model,  is  not  feasible  for  the 
C2  domain.  Fortunately,  this  problem  is  not  unique  to  the  C2  community,  and  we  can  learn  from 
several  other  communities  that  are  answering  these  questions  through  the  use  of  domain 
ontologies. 


Ontology  Defined 

There  are  many  differing  definitions  and  perspectives  on  the  term  “ontology”,  which  is 
somewhat  ironic  because  ontology  is  concerned  with  creating  accurate  descriptions  of  the  world 


in  order  to  have  a  shared  understanding.  Some  of  these  different  perspectives  can  be  attributed  to 
relative  inexperience,  however,  there  is  also  lack  of  a  consistent  definition  of  ontology,  ontology 
terminology,  and  ontological  relationships  even  amongst  professionals  who  are  engaged  in 
applying  ontology  in  various  fields  of  study.  [6]  This  section  reviews  some  of  the  different 
perspectives  on  ontology  and  offers  a  working  definition  for  a  C2  domain  ontology. 

The  term  ontology  originates  in  the  realm  of  philosophy  and  translates  roughly  as  “the  study  of 
being”,  from  the  Greek  “onto”  (“of  being”)  +  “logy”  (“to  study”).  Merriam  Webster  gives  two 
definitions  of  ontology  [7]: 

1  :  a  branch  of  metaphysics  concerned  with  the  nature  and  relations  of  being 

2  :  a  particular  theory  about  the  nature  of  being  or  the  kinds  of  things  that  have  existence 

A  more  descriptive  definition,  still  with  a  philosophical  bent,  is  found  in  Wikipedia  [8]: 

The  study  of  the  nature  of  being,  existence  or  reality  in  general,  as  well  as  of  the  basic 
categories  of  being  and  their  relations.  Traditionally  listed  as  a  part  of  the  major  branch 
of  philosophy  known  as  metaphysics,  ontology  deals  with  questions  concerning  what 
entities  exist  or  can  be  said  to  exist,  and  how  such  entities  can  be  grouped,  related  within 
a  hierarchy,  and  subdivided  according  to  similarities  and  differences. 

Per  Smith  and  Klagges  [9],  the  field  of  applied  ontology  has  its  roots  with  early  philosphers  such 
as  Aristotle  (384-322  BCE),  who  tried  to  make  sense  of  a  complex  world  by  categorizing  and 
documenting  its  entities  and  their  relationships.  Very  well  known  ontologies  are  taxonomies  of 
organisms,  as  well  as  hierarchical  categories  for  the  classification  of  diseases.  Modem 
philosphers  working  in  the  field  of  ontology  continue  the  pursuit  of  dividing,  grouping,  and 
describing  the  world  within  the  discipline  of  applied  philosphy,  and  wrestle  with  ideas  such  as 
realism  vs.  relativism,  realist  fallibilism,  realist  perspectivalism,  granularity,  partitioning,  and 
what  'is_a'  is1  .[1 1] 

As  the  amount  of  data  supporting  a  variety  of  scientific,  medical,  government,  and  business 
applications  has  exploded  with  automation,  there  is  an  imperative  to  better  organize  this 
information  in  order  to  make  it  more  useful.  Just  as  philosophy-based  ontology  tries  to  make 
sense  of  the  world  by  categorizing  and  documenting  its  entities  and  their  relationships, 
information  managers  also  try  to  make  sense  of  vast  amounts  of  data  by  grouping,  subdividing, 
and  arranging  it  in  hierarchies,  as  well  as  creating  various  relationships  between  entities  and 
types  of  information.  Thus,  the  term  ontology  has  also  found  its  way  into  the  vocabulary  of 
Information  Science  in  areas  such  as  data  modeling,  artificial  intelligence,  and  knowledge 
engineering.  In  the  Information  Science  domain,  the  Wikipedia  definition  [12]  of  ontology  is  as 
follows: 

Ontology:  a  formal  representation  of  a  set  of  concepts  within  a  domain  and  the 


1  'is_a'  is  one  of  the  basic  relations  found  in  ontology,  along  with  'has  a'.  It  has  been  noted  that  there  are  at 

least  4  different  types  of 'is_a'  relationships.  [10] 


relationships  between  those  concepts.  It  is  used  to  reason  about  the  properties  of  that 
domain,  and  may  be  used  to  define  the  domain. 


Another  widely  quoted  definition  in  Information  Science  is  that  of  Gruber  [13]: 

Ontology:  “a  formal,  explicit  specification  of  a  shared  conceptualization" 

While  not  directly  included  in  these  definitions,  it  can  be  inferred  that  ontologies  of  interest  in 
Information  Science  are  represented  via  means  suitable  for  automation,  or  are  implemented 
directly  within  the  underlying  data  structures  or  exchanges.  In  some  circles,  the  term  ontology  is 
taken  to  imply  only  those  formal  specifications  that  are  expressed  in  an  ontological  language 
such  as  the  Ontological  Web  Language  (OWL),  a  standard  favored  by  the  World  Wide  Web 
Consortium  (W3C)  [14].  However,  a  more  general  interpretation  of  the  term  is  not  limited  to 
artifacts  represented  in  an  ontological  language,  and  includes  taxonomies,  controlled 
vocabularies,  data  dictionaries,  thesauri,  conceptual  models,  and  a  number  of  other  information 
modeling  artifacts  specified  using  a  variety  of  tools.  This  type  of  perspective  is  reflected  in  the 
DoD  Net-Centric  Data  Strategy,  which  refers  to  COI  vocabulary,  taxonomies,  and  XML  schema 
artifacts  as  ontologies. 

A  notable  difference  between  the  philosophical  and  information  science  definitions  of  ontology 
above  is  that  the  philosophical  definition  stresses  the  modeling  of  reality,  whereas  the 
information  science  definition  stresses  the  modeling  of  concepts.  This  is  an  important  distinction 
in  the  philosophical  realm,  particularly  to  ontologists  who  are  realists.  That  is,  they  believe  there 
is  one  reality,  and  all  ontology  efforts  should  strive  to  represent  reality  vice  concepts  that  may  not 
reflect  reality  at  all.  The  realist  approach  is  strongly  advocated  by  Smith  [15],  Grenon  [16],  and 
others. 

One  way  of  separating  the  difference  between  reality,  concepts,  and  the  artifacts  that  represent 
them  is  to  divide  entities  into  three  levels  as  proposed  by  Smith  [6]: 

•  Level  1  Entities  (reality):  The  objects,  processes,  qualities,  states,  etc.  in  reality. 

•  Level  2  Entities  (concepts):  Cognitive  representations  of  this  reality  on  the  part  of 
researchers  and  others. 

•  Level  3  Entities  (artifacts ) :  concretizations  of  these  cognitive  representations  in  (for 
example  textual  or  graphical)  representational  artifacts. 

For  the  purposes  of  this  paper,  we  are  interested  in  ontology  as  applied  to  information  sharing 
within  and/or  about  the  C2  domain  via  automated  means.  Drawing  largely  from  Smith's  proposed 
reference  terminology  for  ontology  in  the  biomedical  domain2  [6],  our  working  definition  of  a 
C2  domain  ontology  is  as  follows: 


2  Smith  [6]  defines  ontology  as  “a  representational  artifact,  comprising  a  taxonomy  as  a  proper  part,  whose 
representational  units  are  intended  to  designate  some  combination  of  universals,  defined  classes,  and  certain 
relations  between  them.”  He  also  notes  that  an  ontology  must  be  converted  into  a  formalized  representation  if  it 
is  to  be  interpretable  by  a  computer. 


C2  Domain  Ontology:  A  composite  formalized  representational  artifact,  comprising  a 
taxonomy  as  proper  part,  whose  representational  units  designate  C2  universals,  defined 
classes,  and  relations  between  them.  The  C2  domain  ontology  may  be  used  as  a  reference 
to  describe  and  reason  about  C2  in  general,  or  about  C2  particulars  when  applied  to  a 
dataset  pertaining  to  these  particulars. 

Thus,  the  C2  domain  ontology  is  a  collection  of  artifacts  (level  3)  that  describe  C2  entities, 
processes,  qualities,  etc.  (level  1)  based  on  how  C2  subject  matter  experts  collectively  conceive 
of  C2  (level  2).  Further,  these  artifacts  must  be  machine  readable  or  otherwise  suitable  for 
automation.  In  this  definition,  the  term  universals  refers  to  general  types  of  entities  (e.g.,  soldier, 
readiness  level,  personnel  recovery),  as  opposed  to  instances  of  universals,  or  particulars  (e.g., 
Sargeant  Smith,  1st  Battalion  readiness  level,  recovery  operation  “OUT”).  A  defined  class  is  a 
collection  of  particulars  described  by  a  general  term  (e.g.,  Charlie  Platoon,  Army  readiness 
levels,  Joint  C2  processes,).  Relations,  such  as  'instance_of  and  'part_of,  describe  the 
correspondence  between  two  entities  via  tuples  (e.g.,  Sargent  Smith  instance_of  soldier,  Sargent 
Smith  part_of  Charlie  Platoon,  Sargent  Smith  engaged Jn  recovery  operation  OUT). 

Per  discussion  in  a  recent  C2  Ontology  Technical  Exchange  held  in  the  U.S.  [17],  there  are 
three  types  of  artifacts  needed  to  describe  the  C2  domain:  1)  A  natural  language  vocabulary 
explicitly  describing  C2  representational  units,  2)  An  OWL  Description  Logic  (OWL-DL) 
instantiation  of  the  C2  representational  units,  depicting  universals,  defined  classes,  and  the 
relations  between  them,  and  3)  Rules  (e.g.  constraints)  about  the  C2  representational  units 
expressed  in  a  logic  language  such  as  the  Sematic  Web  Rule  Language  (SWRL)  [18],  The  use  of 
OWL-DL  and  SWRL  as  opposed  to  any  other  ontological  language  is  not  absolutely  necessary, 
but  it  is  preferred  for  military  use  based  on  the  designation  of  the  W3C  standards  as  DoD  and 
NATO  standards  and  their  growing  popularity.  In  addition,  the  DoD  Metadata  Registry  (MDR) 
supports  OWL-DL  artifacts,  although  only  the  taxonomic  relations  of  'is_a'  and  'part_of  are 
currently  recognized.  [19] 

Ontology  Types  and  Applications 

Before  discussing  the  feasibility  of  a  C2  domain  ontology,  it  is  useful  to  review  some  ontology 
types  and  applications,  as  well  as  some  real  world  ontologies  that  are  in  use  in  the  biological, 
medical,  and  engineering  domains. 

The  applications  of  ontology  are  as  varied  as  the  number  of  information  domains  that  exist  and 
are  limited  only  by  knowledge  of  the  domain,  the  quality  of  the  ontology  artifacts  and  associated 
tools,  and  the  creativity  of  the  user  in  applying  the  ontologies  to  the  problems  within  a  given 
domain.  Common  ontology  applications  are  to  organize  information  within  a  domain,  to 
integrate  disparate  information  representations  within  a  domain  or  across  domains,  and  to  infer 
new  information  about  a  domain  by  applying  the  ontological  relations  within  and  across 
datasets3.  The  process  of  developing  ontologies  also  advances  knowledge  of  the  domain,  which 


3  For  example,  if  we  know  from  one  dataset  that  Nutmeg  is_a  dog,  and  from  another  dataset  that  a  dog  is  a 

mammal,  we  can  combine  this  information  and  infer  that  Nutmeg  is_a  mammal  if  we  know  that  the  'is  a'  relation 


is  then  captured  in  the  ontologies  and  can  become  powerful  learning  aids  for  others.  The 
ontologies  may  then  serve  as  a  focal  point  for  refining,  extending,  or  otherwise  further  advancing 
knowledge  of  the  domain.  Overall,  ontologies  support  information  sharing  and  understanding 
within  and  across  domains,  whether  it  is  the  general  information  about  the  domain,  or  the 
particulars  within  the  domain  when  the  ontology  is  applied  to  data  about  these  particulars. 


There  are  several  distinct  types  of  ontologies,  and  multiple  ontologies  are  used  in  combination  to 
describe  a  particular  domain  relative  to  the  larger  world  in  which  it  resides  Some  may  refer  to  a 
set  of  ontologies  in  the  singular,  e.g.,  as  we  have  above  with  respect  to  the  C2  Domain  Ontology. 
However,  it  should  be  noted  there  are  usually  multiple  ontological  artifacts  required  to  describe  a 
domain  of  any  substance,  particularly  one  as  complex  as  C2.  This  is  because  there  are  a  number 
of  different  perspectives  to  address,  all  of  which  may  be  valid  in  a  particular  context* 4.  In 
addition,  one  ontology  artifact  may  leverage  several  others  to  fully  describe  an  entity.  Ontology 
types  commonly  referred  to  include  formal  ontologies,  upper-level  ontologies,  intermediate 
ontologies,  mid-level  ontologies,  regional  ontologies,  lower-level  ontologies,  domain  ontologies, 
material  ontologies,  reference  ontologies,  and  application  ontologies.  Depending  on  what  type 
of  formal  or  upper-level  ontology  may  be  in  use,  there  is  also  a  distinction  between  ontologies 
that  describe  continuents  (i.e.,  entities  that  have  substance  and  a  presence,  such  as  a  person  or  a 
rock),  and  occurents  (i.e.,  entities  that  do  not  have  substance  or  presence,  such  as  a  process  or  an 
event).  [21] 

Figure  1,  adopted  from  [16],  depicts  the  concept  of  ontological  levels  for  a  post  office  application 
based  on  the  Husserl  [23]  distinction  between  formal  level  ontologies  characterized  by  being 


is  transitive. 

4  The  term  realist  perspectivalism  captures  the  idea  that  we  can  obtain  knowledge  of  reality  through  multiple  valid 
views  of  reality,  all  of  which  can  be  partitions  of  an  ontology.  For  example,  C2  ontologies  representing  the 
structure  of  C2  organizations,  objects  on  the  battlefield,  and  c2  processes  are  all  valid  perspectives  of  C2. 
Collectively  these  different  perspectives  contribute  to  a  robust  and  realistic  representation  of  the  C2  domain.  [20] 


domain-neutral,  and  regional  level  ontologies,  characterized  by  being  domain-specific5.  As 
shown,  the  most  general  and  domain-neutral  ontology  is  at  the  formal  level,  and  the  specificity  of 
the  ontologies  to  a  given  domain  increases  downward  through  the  intermediate  and  regional 
levels.  There  can  be  multiple  intermediate  levels,  with  the  requirement  that  an  intermediate 
ontology  applies  to  two  or  more  regional  level  ontologies.  Actual  instances  of  universals 
(particulars)  are  shown  along  the  bottom  of  the  diagram  and  map  to  the  regional  level  ontology. 
The  first  vertical  line  from  the  left  delineates  between  ontologies  for  persons  or  material  objects, 
and  the  second  vertical  line  delineates  between  ontologies  pertaining  to  substances  (continuents) 
and  those  pertaining  to  processes  (occurents),  thus  depicting  that  it  is  possible  to  have  multiple 
ontologies  in  use  at  the  intermediate  and  regional  levels.  Formal  level  ontologies  are  also  called 
upper  level  ontologies,  and  intermediate  level  ontologies  are  also  called  mid  level  ontologies. 
Regional  level  ontologies  are  referred  to  as  lower  level  ontologies,  material  ontologies,  and 
domain  ontologies.  Reference  ontologies  are  those  that  describe  universals,  and  application 
ontologies  are  those  that  describe  particulars  through  application  of  a  reference  ontology. 

The  number  of  ontologies  required  to  describe  a  domain  is  unlimited,  depending  on  the 
complexity  of  the  subject  matter  and  the  scope  of  each  ontology  that  is  employed.  In  this 
layering  concept,  there  is  one  formal  level,  but  it  could  conceivably  include  multiple  formal 
ontologies  if  the  intermediate  ontologies  stem  from  multiple  formal  ontologies.  Below  the 
formal  level  there  may  be  multiple  intermediate  levels,  and  each  intermediate  level  may  include 
multiple  ontologies  depending  on  the  scope  of  the  domain  and  the  number  of  intermediate  level 
ontologies  that  are  applicable.  There  may  also  be  multiple  regional  or  domain  ontologies,  but 
each  is  characterized  as  being  specific  to  the  domain  in  question  and  collectively  they  define  the 
domain.  An  important  point  to  note  is  that  the  categorization  of  ontologies  as  intermediate  or 
regional  is  a  function  of  the  granularity  of  the  analysis.  A  regional  ontology  in  a  coarse  grained 
analysis  (e.g.,  at  the  organism  level  in  biology)  may  be  an  intermediate  ontology  in  a  finer 
grained  analysis  (e.g.,  at  the  cell  level).  Characterization  of  ontologies  as  being  in  the  formal 
level  appears  to  be  more  absolute,  although  not  all  ontologies  that  claim  to  be  upper-ontologies 
or  formal  ontologies  actually  meet  the  requirements.  [16] 


l  BFOj 


A  _ 

/  \  i DOLCE 

Upper 


-  Ontologies''-^ 


BioTop  L_ _A 
A 


/ 


Z. 


Top  Domain  . 
Ontologies 


Simple 
Bio  Upper 
___-i  Ontology 

k 


Gene  Ontology  | 

7 -  ^ 

/ 

Z _ 


GENIA 
I - 

— \ 

\ 


Domain  Ontologies 


OBO  (SO, 
ChEBI, 


Figure  2:  Ontological  Layering  in  the  Biological 
Domain  (Stenzhorn  [37]) 


Numerous  real-world  ontologies  have 
been  created  and  are  in  use  in  various 
fields  of  study,  most  notably  in 
biology  and  medicine  where  ontology 
applications  appear  to  be  very 
prevalent,  fairly  mature,  and  widely 
accepted.  Well  known  upper-level  or 
formal  ontologies  include  the  Basic 
Formal  Ontology  (BFO)  [24][25],  the 
Suggested  Upper  Merged  Ontology 
(SUMO)  [26],  and  the  Descriptive 
Ontology  for  Linguistics  and 


5 


In  this  discussion,  the  term  domain  refers  to  the  specific  topic  area  that  the  ontologist  seeks  to  describe  via  the 
ontology. 


Cognitive  Engineering  DOLCE  [21]. 

Notable  domain  ontologies  include  the  Genome  Ontology  (GO)  [28],  the  Unified  Medical 
Language  System  (UMLS)  Semantic  Network  [29],  and  the  large  collection  of  ontologies  that 
are  part  of  the  Open  Biological  Ontology  (OBO)  Foundry.  [30]  These  are  very  comprehensive 
artifacts  that  represent  a  vast  amount  of  domain  knowledge  and  which  are  in  active  use.  The  GO 
provides  approximately  24,000  terms  organized  into  3  ontologies  to  describe  gene  products 
according  to  their  associated  biological  processes,  cellular  components,  and  molecular  functions. 
The  UMLS  is  a  thesaurus-like  ontology  that  facilitates  biomedical  information  retrieval  and 
understanding  and  comprises  over  1  million  biomedical  concepts  and  5  million  concept  names 
stemming  from  over  100  incorporated  controlled  vocabularies  and  classification  systems.  Finally, 
the  OBO  Foundry  includes  over  60  biomedical  ontologies  from  participating  members,  with  the 
vision  that  a  core  of  these  ontologies  will  become  fully  interoperable  by  virtue  of  a  common 
design  philosophy  and  implementation.  Figure  2,  from  Stenzhom  [37],  illustrates  the 
relationship  between  upper  level  ontologies,  mid  level  ontologies  (referred  to  as  “top  domain” 
ontologies  in  the  diagram)  and  domain  ontologies  in  the  biological  domain. 

Another  significant  ontology  effort  is  the  National  Aeronautics  and  Space  Administration 
(NASA)  Exploration  Initiatives  Ontology  Models  (NexIOM),  supporting  the  NASA 
Constellation  program.  NeXIOM  is  a  family  of  approximately  140  ontologies  working  across 
hundreds  of  datasets.  NexIOM  formalizes  the  way  computers  and  people  refer  to  NASA 
Elements,  their  Scientific  and  Engineering  disciplines,  related  work  activities,  and  their 
interrelationships  throughout  the  NASA  Constellation  Program  As  a  result,  information  can  be 
found,  aggregated  and  reasoned  over  to  generate  products,  enable  interoperability  between 
systems  and  tools,  and  inform  decisions.  Figure  3,  illustrating  the  NASA  ontology  architecture, 
gives  a  hint  as  to  the  scope  and  complexity  of  this  work  supporting  multiple  domains, 
disciplines,  and  organizations.  [31] 


NASA  Ontology  Architecture  is  organized 
by  Domain,  Disciple,  Organization  —  each 
with  levels  of  specificity. 


Figure  3:  NASA  Ontology  Architecture  (from  Hodgson  [31]) 


As  further  evidence  of  the  growth  in  the  use  of  ontology,  libraries  of  ontological  artifacts  and 
ontology  search  engines  are  now  available  on  the  world  wide  web.  [32] [33]  While  this  illustrates 
that  ontology  is  poised  to  hit  the  main  stream  of  information  management,  at  least  for  web 
applications,  it  should  be  noted  that  not  all  ontology  is  good  ontology.  In  the  compilation 
Applied  Ontology,  an  Introduction  [11],  multiple  authors  make  the  case  that  many  ontology 
development  efforts  are  using  ad  hoc  methods  and  are  not  following  basic  principles  for 
developing  ontology  as  practiced  by  ontological  engineers  in  the  emerging  field  of  Applied 
Ontology6.  For  example,  “casual”  ontologists  are  not  likely  to:  follow  best  practices  for  defining 
vocabulary  terms  and  creating  useful  classifications  [35],  understand  the  basic  ontological 
relations  and  their  meaning  [36] [10],  understand  how  to  partition  a  domain  [20],  nor  understand 
the  benefits  of  realism.  [15]  [16]  Furthermore,  they  may  not  be  aware  of  work  that  others  have 
done  and/or  whether  it  is  suitable  for  reuse.  As  a  result,  many  existing  ontologies  do  not 
accurately  represent  domain  knowledge,  do  not  leverage  accepted  ontologies  from  other 
domains,  and  do  little  to  solve  the  existing  knowledge  management  and  interoperability 
problems  that  resulted  from  equally  ill-conceived  information  management  approaches  in  the 
past.  If  C2  domain  ontology  development  were  to  proceed  in  this  manner,  the  C2  community 
would  be  no  better  off  using  ontology  technology  than  with  the  current  approach  to  COIs.  That 
is,  there  would  be  multiple,  disparate  ontologies  developed  independently  with  no  standard 
relations,  no  agreed  to  partitioning  of  the  mission  space,  inconsistent  adherence  to  doctrine  or 
existing  standards,  etc.  In  that  case,  we  would  need  still  more  ontologies  to  integrate  these 
ontologies  after  the  fact  in  a  never  ending  spiral.  Information  management  and  interoperability 
problems  would  continue  to  persist,  or  perhaps  even  worsen. 

C2  Domain  Ontology 

The  C2  community  can  clearly  benefit  from  the  use  of  ontology  because  of  the  need  to  organize, 
integrate,  and  understand  large  quantities  of  information  in  order  to  make  effective  decisions. 

This  is  true  whether  the  ontology  is  used  to  support  C2  concept  development,  C2  capability 
management,  C2  materiel  development,  C2  training,  or  real-time  C2  decision  making  and 
information  integration  during  operations.  While  the  full-scale  development  of  an  authoritative 
C2  domain  ontology  has  not  been  directed  by  the  C2  governance  bodies  in  the  U.S.  or  NATO7, 
both  bodies  have  begun  exploring  the  practical  application  of  ontology  to  C2.  For  example, 
NATO  hosted  two  ontology  workshops  in  2008  and  a  third  in  March  2009,  the  NATO  Semantic 
Interoperability  Group  is  investigating  the  applicability  of  ontology  to  facilitate  semantic 
interoperability,  and  the  forthcoming  NATO  Data  Strategy  Implementation  Guidance  will  include 
a  volume  on  “Ontology  and  Vocabulary”.  In  the  U.S.,  the  U.S.  Joint  Forces  Command,  U.S. 
Army  Software  Center  of  Excellence,  and  the  Buffalo  University  National  Center  for  Ontological 
Research  held  a  C2  Ontology  Technical  Exchange  in  February  2009  to  assess  the  state  of  the  art 
of  C2  ontology  efforts,  and  there  are  several  independent  efforts  underway  exploring  the  use  of 
ontology  for  a  variety  of  C2  applications.  Collectively,  these  activities  show  that  the  idea  of 


6  Applied  Ontology  is  “a  branch  of  applied  philosophy  using  philosophical  ideas  and  methods  from  ontology  in 
order  to  contribute  to  a  more  adequate  presentation  of  the  results  of  scientific  research.”  [34] 

7  The  formal  U.S.  C2  governance  body  is  the  C2  Capability  Integration  Board  (C2  CIB).  The  formal  NATO  C2 
governance  body  is  the  NATO  C3  Board  (NC3B). 


applying  ontology  to  C2  has  taken  hold,  and  undoubtedly  there  are  similar  activities  underway  in 
other  nations.  As  further  evidence,  there  have  been  a  steady  stream  of  C2  ontology  papers 
presented  at  the  ICCRTS,  Simulation  Interoperability  Standards  Organization  (SISO),  and 
elsewhere  regarding  C2  ontology,  many  of  which  explore  the  use  of  the  Joint  Consultation, 
Command,  and  Control  Information  Exchange  Data  Model  (JC3IEDM)  as  discussed  below. 


Given  the  strong  interest  in  the  use  of  ontology  for  C2,  how  far  is  the  C2  community  from 
creating  a  C2  domain  ontology  that  can  support  C2  capability  development  and  management,  C2 
data  and  service  interoperability  and  integration,  operational  decision  making,  training,  or  any 
type  of  practical  application?  Based  on  our  working  definition  of  a  C2  domain  ontology  in  a 
previous  section,  one  might  argue  that  the  C2  community  is  already  well  on  the  way  to  creating  a 
C2  domain  ontology.  That  is  because  many  C2  architecture,  data,  and  modeling  initiatives  may 
be  considered  forms  of  ontology,  or  at  least  promising  candidates  for  contributing  to  a  C2 
domain  ontology.  In  addition,  the  formal  description  of  C2  entities,  vocabulary,  and  processes 
within  doctrine  can  also  serve  as  strong  contributors  to  a  C2  domain  ontology.  Several  of  the 
most  relevant  C2  ontology-like  efforts  and  artifacts  are  described  in  the  following  paragraphs. 


Joint  Capability  Areas  (JCA)  and  Universal  Joint  Task  List  (UJTL) 

The  JCAs  are  a  U.S.  DoD  construct  for  partitioning 
DoD  capabilities  into  separate  functional  areas.  The 
JCAs  are  described  by  a  taxonomy  and  a  set  of 
definitions  for  each  element  in  the  taxonomy.  [41]  At 
the  top  level  (Tier  1),  there  are  9  JCA's,  one  of  which 
is  Command  and  Control8,  and  the  hierarchy  of 
capabilities  extends  several  levels,  providing  4  levels 
for  C2.  JCAs  have  become  an  important  organizing 
construct  for  management  purposes,  e.g.,  within  the 
Joint  Capability  Integration  and  Development 
System  (JCIDS)  [42],  and  should  also  be  an 
important  part  of  a  C2  domain  ontology.  This  is 
because  the  JCA  construct  provides  a  taxonomy  and 
vocabulary  for  defining  C2  from  the  process 
perspective,  and  the  Tier  1  JCAs  could  be  considered 
part  of  an  intermediate  ontology  which  relates  C2  to 
the  larger  scope  of  the  DoD  capability  domain. 

Figure  4  shows  an  excerpt  of  the  C2  JCA  taxonomy  for  arguably  the  most  important  Tier  2 
capability,  Planning.  The  DoD  Core  Taxonomy,  an  OWL  taxonomy  in  the  DoD  Metadata 
Registry,  is  based  on  the  JCA  structure.  A  similar  product  to  the  JCAs  is  the  Universal  Joint  Task 
List  (UJTL).  The  UJTL  is  a  common  language  and  reference  system  arranged  in  a  hierarchical 
manner  that  enables  users  to  unambiguously  describe  and  communicate  U.S.  military  missions 
and  tasks.  [43]  While  the  best  known  functions  of  the  UJTL  are  to  support  the  Joint  Training 
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Figure  4:  C2  Planning  JCA  (Tier  2-4) 


8  The  remaining  8  Tier  I  JCAs  are:  Force  Application,  Battlespace  Awareness,  Net-Centric,  Building  Partnerships, 
Logistics,  Force  Support,  and  Corporate  Management  and  Support 


System  and  readiness  reporting,  the  UJTL  also  serves  as  a  description  and  taxonomy  of  the  types 
of  tasks  that  are  performed  in  the  conduct  of  C2  or  other  capabilities,  and  is  therefore  an 
important  component  of  a  C2  domain  ontology.  The  U.S.  Joint  Chief  of  Staff  J7,  which  owns 
both  the  JCAs  and  UJTLs,  maintains  a  mapping  between  the  two. 

C2  Core 

The  C2  Core  is  a  U.S.  DoD  effort  led  by  U.S.  Joint  Forces  Command  (USJFCOM)  and  the 
Office  of  the  Assistant  Secretary  of  Defense  for  Networks  and  Information  Integration 
(OASD(NII))  in  their  role  as  co-leads  of  the  C2  Capability  Portfolio.  The  intent  of  the  C2  Core 
is  to  enable  greater  information  interoperability  within  the  C2  domain  through  the  use  of  a 
common  structural  and  semantic  foundation  for  the  creation  of  XML-based  C2  information 
exchanges.9  The  C2  Core  is  currently  under  development  with  a  baseline  version  to  be  available 
in  Jun  2009  that  will  include  a  C2  conceptual  model  and  vocabulary  as  well  as  XML  reference 

schemas  that  are  C2-specific  extensions  to  the  U.S. 
Universal  Core  (UCore)10.[5][44]  The  conceptual  model 
and  vocabulary  components  of  the  C2  Core  are  highly 
relevant  to  the  creation  of  a  C2  domain  ontology  because 
they  will  describe  the  universals  that  are  of  interest  within 
the  C2  domain,  such  as  organizations,  individuals, 
weapons,  vehicles,  plans,  orders,  and  effects.  These  are  the 
continuents  of  the  C2  domain  and  can  form  the  basis  for 
more  sophisticated  occurrent  or  process  ontologies.  The 
close  relationship  of  the  C2  Core  to  the  UCore  is  also 
important  to  an  eventual  C2  domain  ontology  because  the 
UCore,  if  coupled  with  additional  semantics,  will  then  be 
an  intermediate  ontology  for  the  C2  domain  ontology.  In 
fact,  there  are  reportedly  efforts  to  create  a  UCore 
Semantic  Layer  (UCore-SL)  represented  in  OWL,  and 
possibly  to  map  the  UCore  to  a  true  upper  ontology* 1 1 .  In  that  case,  the  upper  ontology,  UCore- 
SL,  and  the  C2  Core,  if  represented  as  an  ontology,  would  form  a  hierarchy  of  ontologies  for  C2 
and  the  basis  for  further  work  at  the  COI-level.  Figure  X  shows  the  hierarchical  relationship 
between  the  UCore,  C2  Core,  and  COI-specific  extensions  within  a  C2  Core  compliant 
Information  Exchange  Specification  (IES). 

JC3IEDM 

JC3IEDM  is  a  product  of  the  Multilateral  Interoperability  Programme  (MIP)  and  is  endorsed  by 
the  NC3B  as  NATO  Standard  Agreement  (STANAG)  5525.[46][47]  The  JC3IEDM  is  important 
to  the  C2  domain  ontology  because  it  is  a  very  comprehensive  representation  of  the  data  that  is 


Figure  5:  C2  Core-based  IES 


9  While  the  emphasis  on  the  C2  Core  is  on  XML-based  messages  due  to  the  emphasis  of  current  standards,  the  C2 
Core  Conceptual  Model  and  Vocabulary  may  also  apply  to  other  types  of  messages. 

10  The  UCore  is  a  U.S.  DoD,  Department  of  National  Intelligence,  Department  of  Justice,  and  Department  of 
Homeland  Security  common  framework  for  XML-based  messages  that  includes  the  basic  concepts  of  “who”, 
“what”,  “when”,  and  “where” 

1 1  MITRE  investigated  the  use  of  upper  ontologies  for  government  and  military  applications  in  [45], 


shared  between  coalition  partners  to  perform  C2  functions,  and  it  codifies  at  least  20  years  of 
work  by  C2  domain  experts  based  on  C2  doctrine.  Important  components  of  the  JC3IEDM  that 
may  contribute  to  a  C2  domain  ontology  include  the  conceptual  data  model,  logical  data  model, 
an  extensive  vocabulary,  and  many  controlled  vocabularies.  In  addition,  the  JC3IEDM 
documentation  includes  extensive  rules  governing  the  relationships  between  JC3IEDM  entities 
as  well  as  their  allowable  values,  which  is  invaluable  for  verifying  whether  a  given  message  or 
information  artifact  is  valid.  There  have  been  many  papers  regarding  the  value  of  JC3IEDM  as  a 
C2  ontology,  most  finding  that  while  there  is  goodness,  it  is  not  a  ready  made  solution  for  a  C2 
domain  ontology.  [48] [49] [50]  Recently  the  Institute  for  Defense  Analyses  created  an  OWL-DL 
version  of  the  JC3IEDM  for  the  MIP  community.  An  important  finding  was  that  while  OWL-DL 
was  able  to  capture  much  of  the  model,  an  additional  rules  language  such  as  SWRL  is  needed  to 
fully  capture  the  relationships  of  the  JC3IEDM.[5 1]  It  is  expected  that  the  JC3IEDM  conceptual 
model  and  vocabulary  will  have  a  significant  role  in  the  emerging  C2  Core.  However,  there  are 
many  other  sources  of  similar  information  that  will  be  considered  to  include  Tactical  Data  Link 
standards,  Message  Text  Lormat  standards,  and  the  work  of  C2-related  COIs  to  the  extent  that 
they  are  accurate  representations  of  C2  vocabularies,  entities,  and  relationships. 

COI  and  Program  Vocabularies  and  Taxonomies 

As  described  previously,  COIs  are  the  stated  U.S.  and  NATO  approach  to  implementing  a  net- 
centric  data  sharing  approach  for  a  specific  operational  need.  Examples  of  C2-related  COIs  in 
the  U.S.  include  the  Time  Sensitive  Targeting  COI,  the  Blue  Lorce  Tracking  COI,  the  Joint  Air 
and  Missile  Defense  COI,  the  Air  Operations  COI,  the  Maritime  Domain  Awareness  COI,  and 
the  Global  Strike  COI.  In  accordance  with  U.S.  DoD  guidance  [52],  each  of  these  COIs  is 
producing  semantic  products  that  describe  the  data  shared  within  the  COI,  to  include 
vocabularies,  XML  schemas,  taxonomies,  and  sometimes  additional  components  such  as  logical 
data  models,  Business  Process  Language  (BPL)  artifacts,  and  U.S.  DoD  Architectural 
Lramework  (DoDAF)  [53]  products  that  describe  the  processes  of  the  COI.  While  none  of  these 
COIs  is  concerned  with  developing  a  C2  domain  ontology  in  and  of  itself,  they  are  important 
nonetheless  because  they  may  share  entities  with  the  C2  domain,  model  part  of  the  C2  domain, 
or  represent  the  lower  ontologies  that  build  from  the  C2  domain.  Thus,  the  work  of  the  C2- 
related  COIs  can  help  define  the  C2  domain  ontology  from  the  “bottom  up”,  whereas  the  UCore 
and  the  JCAs  help  build  the  C2  ontology  from  the  “top  down”.  In  addition,  COIs  such  as 
Logistics,  Distribution,  Global  Force  Management,  Meteorology  and  Oceanography  (METOC), 
and  Measurement  and  Signal  Intelligence  (MASINT)  can  provide  important  insights  on  domain 
ontologies  that  are  outside  of  the  C2  domain  but  may  be  leveraged  by  the  C2  domain  ontology. 

A  quick  review  of  the  unclassified  version  of  the  DoD  MDR  [19]  in  March  2009  revealed  that 
there  are  very  few  COIs  or  programs  registering  taxonomies,  the  basic  type  of  ontology 
supported  by  the  MDR.  Of  the  approximately  140  namespaces,  only  6  have  registered 
taxonomies  for  a  total  of  180  taxonomies,  with  151  attributed  to  one  namespace  (Focused 
Logistics).  C2  taxonomies  appear  to  be  limited  to  the  NECC-C2  namespace,  where  there  are  18 
artifacts,  most  of  which  are  multiple  versions  of  capability  taxonomies  based  on  the  NECC 
program  structure.  Of  particular  interest  is  a  C2  objects  taxonomy  which  appears  to  be  based  on 
objects  in  the  Military  Standard  (MIL-STD)  2525,  Military  Symbology. 


C2  Architecture  Products 


Over  the  last  decade  or  more,  there  has  been  a  push  toward  creating  extensive  architectural 
documentation  to  uniformly  describe  a  given  capability  and  how  it  fits  into  the  bigger  picture  of 
an  operational  process  or  a  domain  such  as  C2  or  Logistics.  The  DoDAF  and  the  NATO 
Architectural  Framework  (NAF)  [54]  offer  guidelines  for  creating  specific  architectural  products. 
Of  primary  interest  to  a  C2  domain  ontology  are  the  Operational  Views  (OV’s)  of  the 
architecture,  because  they  define  C2  universals:  operational  entities,  the  relationships  between 
them,  the  information  that  is  exchanged,  and  the  relevant  processes  .  While  many  architecture 
products  describe  a  single  capability  or  a  single  operational  process  vice  a  domain,  there  are 
more  comprehensive  “integrated”  architectures  as  well.  A  notable  effort  is  the  USJFCOM- 
developed  Joint  Task  Force  Headquarters  (JTF  HQ)  architecture,  which  describes  the  operational 
nodes  of  a  JTF  HQ,  the  relationships  between  these  nodes,  the  functions  they  perform,  the 
information  that  is  exchanged,  and  many  other  aspects  of  JTF  C2.  Additional  Joint  C2 
architecture  products  offer  detailed  descriptions  of  important  C2  processes,  to  include  Joint  Close 
Air  Support  (JCAS),  Joint  Personnel  Recovery  Activity  (JPRA),  and  Crisis  Action  Planning 
(CAP).  The  JTF  HQ  architecture  products  are  extensively  documented,  map  back  to 
authoritative  references  such  as  policy  or  doctrine,  and  include  a  vocabulary  that  describes  the 
entities  of  the  architecture  (AV-2),  as  well  as  information  exchange  requirements  (OV-3)  that 
describe  the  data  entities  (e.g.,  reports,  messages)  exchanged  by  the  operational  entities.  Because 
the  function  of  the  JTF  HQ  is  C2,  these  integrated  architecture  products  may  be  considered  a 
form  of  a  C2  domain  ontology  in  that  they  describe  C2  entities  and  the  relationships13  between 
them,  as  well  as  important  C2  processes.  These  architecture  products  have  been  mapped  to  key 
external  products  such  as  the  JCA  taxonomy,  the  Joint  Common  Systems  Functions  List14  [55], 
and  the  UJTL,  and  there  are  efforts  underway  to  make  the  architecture  products  and  mappings 
available  as  UCore  and  C2  Core  compliant  XML  artifacts  via  web  services. 

NATO  C2  Conceptual  Model  and  Referent  Tracking 

In  2003,  the  NATO  Research  and  Technology  Office  formed  a  Systems  Analysis  and  Studies 
panel  (SAS-050)  to  explore  new  approaches  to  command  and  control.  [56]  The  primary  goal  of 
the  group  was  to  build  a  conceptual  model  of  C2  that  would  capture  knowledge  about  C2  and 
then  serve  as  a  point  of  departure  for  others  to  explore,  analyze,  and  evaluate  alternative 
approaches  to  C2.  The  result  is  a  C2  conceptual  model  consisting  of  a  Reference  Model,  a  Value 
View,  and  a  generic  C2  process  view.  Whereas  the  architecture  products  above  tend  to  describe 
a  classic,  hierarchical  approach  to  C2  based  on  current  doctrine,  the  SAS-050  product  is  a  more 


12  Operational  Views  are  of 'primary  interest'  because  they  describe  the  universals  of  a  domain  or  process,  whereas 
Systems  Views  and  Technical  Views  describe  specific  instances  of  a  process,  or  the  particulars.  Per  our 
definition,  the  C2  domain  ontology  is  composed  of  universals,  but  it  can  be  used  to  describe  and  reason  about 
particulars.  This  is  exactly  how  the  operational,  system,  and  technical  views  in  the  architecture  work  together. 

13  The  integrated  architecture  products  include  approximately  50  types  of  relations,  which  could  serve  as  the  basis 
for  a  standard  set  of  C2  relations. 

14  The  JCSFL  is  a  very  extensive  3-level  taxonomy  of  the  basic  capabilities  that  systems  provide  in  support  of 
military  capabilities.  While  not  limited  to  C2  functions,  the  JCFSL  include  a  very  detailed  list  of  C2  system 
functions  that  map  to  the  architecture  products  and  could  be  part  of  a  C2  domain  ontology  applied  to  the 
requirements  or  acquisition  processes. 


general  C2  model  that  supports  the  development  and  analysis  of  many  working  models  of  C2 
using  subsets  of  variables  and  relationships  from  the  Reference  Model.  From  an  ontology 
perspective,  the  SAS-050  work  is  of  interest  on  many  levels.  For  example,  the  generic  process 
view  of  C2  can  serve  as  an  overarching  process  model  for  C2  that  is  not  specific  to  Land,  Air, 
Maritime,  Space,  Cyberspace,  or  any  other  operational  domain.  Of  particular  interest  is  that  it 
includes  provision  for  human  dimensions  of  C2  such  as  the  differences  between  individual  and 
unit  characteristics,  behaviors,  awareness,  and  knowledge.  In  addition,  the  C2  Reference  Model 
contains  a  wealth  of  information  regarding  C2  variables  and  relationships  that  may  be  the  basis 
for  developing  sub-ontologies  within  the  C2  domain.  A  very  interesting  perspective  on  the  value 
of  the  SAS-050  model  was  presented  by  Cuesters  [57]  at  the  U.S.  C2  Ontology  technical 
exchange,  where  it  was  shown  that  the  SAS-050  work  aligns  well  with  the  applied  ontology 
layered  framework  of  reality,  concepts,  and  representational  artifacts.  In  addition,  Cuesters  also 
demonstrated  how  the  SAS-050  generic  process  model,  when  combined  with  a  suitable  upper 

ontology  and  the  concept  of  Referent 
Tracking15  [58],  can  model  the  state  of 
reality  at  points  in  time,  including  the 
difference  between  reality,  what  is 
perceived  as  reality  by  a  human  observer, 
and  what  is  captured  as  reality  in  a  C2 
system  (and  thus  the  foundation  for 
shared  situational  awareness).  This  is  a 
powerful  perspective  that  creates  a  bridge 
between  entities  in  the  real  world  and  the 
human-centric  process  of  C2  that  seeks  to 
understand  and  act  upon  them  over  time. 
Figure  6  illustrates  the  concept  of  referent 
tracking,  where  objects  in  reality  are 
mapped  to  the  ontology  through  a 
situational  model  consisting  of  referents. 
The  situational  model  changes  over  time 
as  the  situation  changes,  while  the  ontology  remains  a  constant. 

Summary 

The  previous  section  demonstrates  that  there  are  already  numerous  C2  artifacts  in  existence  or 
under  development  that  can  help  form  the  basis  of  a  C2  domain  ontology  and/or  give  insights  on 
the  development  of  C2  domain  ontology.  In  addition,  there  is  a  wealth  of  applicable  doctrinal 
publications  available  such  as  those  describing  military  terminology,  C2  concepts  and  processes, 
and  various  types  of  materiel,  organizations,  and  individuals  that  are  the  objects  of  C2.[59][60] 
Figure  7  shows  the  approximate  relationship  of  these  C2  products  to  the  levels  of  ontology 
described  in  the  previous  section.  Of  course,  this  is  not  to  say  that  each  of  these  products  follows 
the  principles  of  applied  ontology  and  are  thus  “good  ontology”,  nor  that  the  products  are 


15  The  concept  of  referent  tracking  is  that  each  particular  in  the  real  world  has  a  unique  identity  (a  reference)  that 
can  be  mapped  to  its  corresponding  universal  in  a  domain  ontology.  The  status  of  the  referent  and  its 
relationship  to  the  ontology  may  change  over  time. 


Figure  6:  Referent  Tracking,  Cuesters  [58] 


mutually  compatible.  In  fact,  they  are  certainly  imperfect  from  an  applied  ontology  perspective, 
and  are  known  to  be  incompatible  in  many  regards  because  they  are  each  developed 
independently  from  different  perspectives  using  different  entities,  vocabularies,  and  relations. 
However,  what  it  is  very  promising  is  that  the  C2  domain  is  being  modeled  extensively  and  in 
some  cases  rigorously,  and  the  C2  community  is  looking  toward  ontology  as  a  future  solution. 
Thus,  there  is  a  great  opportunity  to  shape  the  way  ahead. 
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Figure  7:  Ontological  Layering  of  Candidate  C2  Artifacts 


Recommendations  and  Challenges 

The  previous  sections  described  the  need  to  organize  and  share  C2  information  in  a  more  agile 
manner,  what  ontology  is,  how  ontology  is  applied  in  other  domains,  and  how  some  current  C2 
data,  architecture,  and  modeling  efforts  may  contribute  to  an  eventual  C2  domain  ontology. 
Given  this  basis,  what  is  the  way  ahead  for  successfully  building  and  applying  ontology  to  C2? 

Recommendations 

A  number  of  basic  recommendations  for  the  development  of  a  practical  C2  domain  ontology 
follow  from  the  previous  sections,  from  the  discussions  in  the  NATO  and  U.S.  Ontology 
Workshops,  and  from  the  collective  experience  of  the  authors.  Some  of  the  most  important 
recommendations  are  as  follows: 

•  Identify  relevant  and  feasible  applications  of  C2  ontology.  There  is  a  wide  variety  of 


applications  for  C2  domain  ontology,  and  it  is  important  to  focus  initial  efforts  on  applications 
that  are  the  most  relevant  and  feasible.  Modeling  the  continuents  of  the  C2  domain  as  a  basis  for 
information  integration  is  a  good  place  to  start,  e.g.  within  the  C2  Core  effort  and/or  within  one 
or  more  C2 -related  COIs. 

•  Establish  a  common  approach  to  C2  ontology  specification.  This  would  include  a  common 
vocabulary  for  describing  the  components  of  the  ontology,  a  standard  set  of  relations,  a  standard 
set  of  rules/constraints,  preferred  ontology  and  rules  languages,  and  a  set  of  best  practices. 

•  Adopt  the  Realist  Perspective.  Reality  is  the  true  common  denominator  between  independent 
ontology  efforts,  and  thus  ontology  based  on  the  realist  perspective  offers  the  best  opportunity 
for  interoperability.  At  a  practical  level,  this  will  mean  leveraging  C2  Subject  Matter  Experts 
and  doctrine  in  the  ontology  development  process. 

•  Leverage  existing  C2  ontology-like  artifacts  such  as  the  architecture  products  to  the  extent 
that  they  are  accurate  depictions  of  the  C2  domain.  This  will  avoid  excessive  duplication  of 
effort,  will  assist  with  backward  compatibility,  and  will  accelerate  the  development  curve. 

•  Include  key  stakeholders  in  an  open  process  to  include  coalition  and  interagency  partners  to 
allow  convergence  on  a  common  approach.  The  OBO  Foundry  approach  of  making  ontology 
artifacts  openly  available  with  wiki-like  configuration  management  may  be  a  good  model  to 
adopt  for  the  C2  domain. 

•  Foster  C2  community  applied  ontology  awareness  and  expertise  through  increased  access  to 
applied  ontology  workshops,  short  courses,  tools,  and  training  opportunities.  This  statement 
applies  to  ontological  engineers,  operators  and  others  who  would  apply  and  benefit  from  the 
ontology,  to  include  managers  and  decision  makers. 

Challenges 

While  the  above  steps  sound  reasonably  straight  forward,  there  are  still  a  great  number  of 
challenges  and  open  questions  to  resolve  before  an  effective,  large  scale  C2  domain  ontology  is 
in  place.  These  challenges  include: 

•  Huge  scope,  complexity,  diverse  applications,  and  unclear  partitions  and  boundaries  of 
C2; 

•  C2's  dependencies  on  other  warfighting  domains  (e.g.  force  management,  logistics, 
intelligence)  that  also  do  not  have  mature  ontologies  in  place; 

•  The  process-based  nature  of  C2  and  strong  human  element,  which  are  very  difficult  to 
model; 

•  Significant  time  and  resource  requirements;  and 

•  The  constantly  evolving  nature  of  warfare. 

While  these  are  difficult  challenges,  the  C2  community  should  take  heart  in  the  fact  that  these  are 
similar  challenges  that  the  biomedical  community,  NASA,  and  others  are  successfully  tackling. 


The  C2  community  can  benefit  from  the  significant  progress  and  lessons  learned  that  have  been 
made  in  applied  ontology,  as  well  as  the  C2  ontology-like  artifacts  already  developed. 

Summary  and  Conclusion 

Agile  C2  requires  agile  information  sharing  with  an  increasingly  wide  variety  of  military  and 
non-military  partners.  While  current  “net-centric”  approaches  may  improve  information  sharing 
within  a  particular  niche  of  C2,  they  do  not  support  information  sharing  across  the  larger  C2 
domain.  Although  not  a  silver  bullet,  the  development  and  application  of  a  C2  domain  ontology 
to  improve  C2  data  and  service  integration  appears  to  be  increasingly  realistic.  In  fact,  there  are 
several  examples  of  successful  ontology  applications  in  domains  such  as  medicine,  biology,  and 
engineering,  and  the  new  discipline  of  Applied  Ontology  is  emerging.  C2  data,  architecture,  and 
conceptual  modeling  activities  which  bear  a  close  resemblance  to  applied  ontology  activities  are 
also  beginning  to  take  shape,  and  there  are  several  efforts  with  near  to  mid-term  promise  as 
elements  of  a  C2  domain  ontology.  Given  this  state  of  affairs,  it  is  the  authors'  conclusion  that 
development  of  a  partial  but  practical  C2  domain  ontology  is  necessary  and  feasible  in  the  near 
to  mid  term.  At  the  very  least,  the  U.S.  and/or  NATO  C2  community  should  commit  to  some 
near  term  practical  steps  toward  developing  a  basic,  quality  C2  domain  ontology  such  as  those 
outlined  above,  following  the  principles  and  best  practices  of  the  applied  ontology  community. 
These  initial  steps  can  then  pave  the  way  for  follow-on  activities  to  develop  and  grow  a  more 
sophisticated  and  comprehensive  C2  domain  ontology  over  time,  capable  of  supporting  a  broad 
array  of  information  integration  and  decision  support  activities  for  C2  developers,  trainers, 
experimenters,  and  operational  users. 
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Bottom  Line  Upfront 


❖  Development  of  a  practical  C2  domain 
ontology  is  feasible  in  the  near  to  mid  term 

❖  Efforts  should  follow  the  principles  and 
best  practices  of  the  Applied  Ontology 
community  while  reusing  existing  C2 
modeling  artifacts  to  the  extent  practical,  ^ 


What  is  “On 


Philosophy-based  Detnil 


>  Merriam  Webster:[7] 

1.  a  branch  of  metaphysics  concerned  with  the  nature  and 
relations  of  being 

2.  a  particular  theory  about  the  nature  of  being  or  the  kinds  of 
things  that  have  existence 


>  Wikipedia:  [8] 


The  study  of  the  nature  of  being,  existence  or  reality  in 
general,  as  well  as  of  the  basic  categories  of  being  and  their 
relations.  Traditionally  listed  as  a  part  of  the  major  branch  of 
philosophy  known  as  metaphysics,  ontology  deals  with 
questions  concerning  what  entities  exist  or  can  be  said  to 
exist,  and  how  such  entities  can  be  grouped,  rel 


nformation  Science  Definitions 


>  Wikipedia  [12] 

•  A  formal  representation  of  a  set  of  concepts  within  a 
domain  and  the  relationships  between  those 
concepts.  It  is  used  to  reason  about  the  properties 
of  that  domain,  and  may  be  used  to  define  the 
domain 


Gruber  [13] 

A  formal,  explicit  specification  of  a  shared 


Key  T erms  and  Concepts 


>  Realism  vs  Relativism 

>  Realst  Fallbtilism 

>  Realistic  Perspectivism 

>  Universals 

>  Particulars 

>  Classes  . 

>  Relations 

>  Tuples  // 


Entity  Levels 


vel  1  Entities  (reality):  The 
objects,  processes,  qualities, 
states,  etc.  in  reality. 

vel  2  Entities  (concepts): 
Cognitive  representations  of  this 
reality  on  the  part  of  researchers 
and  others. 

vel  3  Entities  (artifacts): 
Comretizations  of  these  cognitive 
representations  in  (for  example 
textual  or  graphical) 
representational  artifacts. 


From  Smith  [6] 


C2  Domain  Ontology  Working 

Definition 

>  C2  Domain  Ontology:  A  composite  formalized 
representational  artifact,  comprising  a  taxonomy  as 
proper  part,  whose  representational  units  designate  C2 
universals,  defined  classes,  and  relations  between  them. 
The  C2  domain  ontology  may  be  used  as  a  reference  to 
describe  and  reason  about  C2  in  general,  or  about  C2 
particulars  when  applied  to  a  dataset  pertaining  to  these 
particulars 

Recommended  artifacts  per  C2  Ontology  Technical  Exchange,  Jan  2009:  [17] 

1 .  A  natural  language  vocabulary  explicitly  describing  C2  representational  units 

2.  An  OWL-DL  instantiation  of  the  C2  representational  units 

3.  Rules  (e.g.  constraints)  expressed  in  a  logic  language  such  as  SWRL 


Ontology  and  the  Semantics  Spectrum 


Strong  Semantics 


^Logical  Theory 


Thesaurus 


List 


Axiology 

Mod  at  Logic 
First  Order  Logic 
Description  Logic 
OWL 
UML 

RDF,  RDF/5 

Topic  Map,  Object  Model 
Entity  Relationship  Model 
Database  Schema,  XML  Schema 
XML,  Relational  Model 
Glossary,  Controlled  Vocabulary 


'Conceptual"  Model 


Taxonomy 


Weak  Semantics 


<=>.  n  > 


From  Obrst,  L.  (2003):  — Ontologies  for  Semantically  Interoperable  Systems,  ||  Proceedings  of  the  Twelfth  International 
Conference  on  Information  and  Knowledge  Management,  November  2003, pp.  366-369. 


Ontology  Types 
Applications 


>  Describe  something  (the  world,  a 
particular  domain) 

>  Organize  information 

>  Integrate  disparate  information 
representations 


Infer  information  about  something  by 


Common  Ontology  Types 


>  Reference  Ontologies 

>  Application  Ontologies 

>  Ontology  Levels 

•  Formal  or  Upper  Level  Ontologies 

•  Intermediate  or  Mid-Level  Ontologies 

•  Regional,  Lower-level,  Material,  or  Domain 
Ontologies 


Simple  Post  Office  Ontology 
Ifflstrating  Ontological  Levels 


Figure  1:  Ontological  Levels  (Adapted  from  [i6],  p68) 


Sample  Upper  Level 

Ontologies 


or  Formal 


>  Basic  Formal  Ontology  (BFO)  pwps] 

>  Suggested  Upper  Merged  Ontology 
(SUMO)  [26] 

>  Descriptive  Ontology  for  Language  and 
Cognitive  Engineering  (DOLCE)  [27] 


Sample  Biological]  Domain  Ontologies 


>  Genome  Ontology  (GO)  [28] 

•  Describes  gene  products  by  associated  processes,  cellular 
components,  and  molecular  functions 

•  24,000  terms  organized  into  3  ontologies 

>  Unified  Medical  Language  System  (UMLS)  Semantic 
Network  [29] 

.  Thesaurus-like  ontology 

.  1  million  biomedical  concepts  &  5  million  concept  names 
stemming  from  100  controlled  vocabula|ies  and  classification 
systems 
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Figure  2:  Ontological  Layering  in  the  Biological  Domain 
(Stenzhorn  [37]) 


NASA  Domain  Onto  ogles 


NASA  Exploration  Initiative  Ontology  Models 
(NexIOM)  [31] 

•  Supports  NASA  Constellation  Program 

•  Family  of  approximately  140  ontologies  working 
across  hundreds  of  datasets 

•  Formalizes  the  way  NASA  computers  and  personnel 
refer  to  NASA  elements,  their  scientific  and 
engineering  disciplines,  related  work  activities,  and 
their  interrelationships 

•  Facilitates  information  retrieval,  aggregation, 


NASA  Ontology  Architecture  is  organized 
by  Domain,  Disciple,  Organization  —  each 
with  levels  of  specificity. 


Graphic  used  with  permission  of  Ralph  Hodgson,  Top  Quadrant  [31] 


Additional  Ontology  Artifacts 

>  Numerous  ontology  artifacts  available  through 
online  libraries  and  search  engines,  e.g. 


>  Illustrates  the  growing  popularity  of  web-based 
ontology  solutions 


SchemaWeb 

•  http://www.schemaweb.info/eb 

OntoSelect 

I B  httpi/olpMifeiade/OntoSelect/ 


Not  all  ontology  is  good  ontology 


Mafjy  (most?)  ontology  development  efforts  are  not 
fQlllowilg  basic  principles  and  best  practices  of  Applied 
Omology,  e.g,  with  respect  toH|HHH|HHHHI 


.  Precise  definition  of  vocabulary  terms 
.  Useful  and  appropriate  classification  schemes 
.  Proper  use  of  basic  ontological  relations 
.  Methods  for  partitioning  a  domain 
.  Rationale  and  benefits  of  the  realist  perspective 
.  Reuse  of  existing  formal,  intermediate,  and  domain 


ontologies 


■v 


C2  Domain  Ontology  Rationale 


>  C2  demands  the  ability  to  organize, 
integrate,  and  understand  large  quantities 
of  information 

>  Application  Areas 

•  Operational  C2 

•  C2  Concept  Development 


Potential  C2  Ontology  Contributors 

C2  Data  Models  &  XML  Schemas  C2  Taxonomies 

>  C2  Core  >  Joint  Capability  Areas 

>  JC3IEDM  >  Universal  Joint  Task  List 

>  C2  CO  I  Artifacts 


C2  Capability  Models 

>  C2  Architecture  Products 
NATO  C2  Conceptual 


Joint  Capability  Areas  (JCAs)  [4i] 


Tier  1  JCAs: 

Command  and  Control  r 

Force  Application 
Battlespace  Awareness 
Net-Centric 
Building  Partnerships 
Logistics 
Force  Support 

Corporate  Management  &  Support 


Tier  2  C2  JCAs: 

Organize 

Understand 

Planning 

Decide 

Direct 

Monitor 


Planning 

Analyse  problem 
dialyze  Situation 
Document  FYoblem  Elements 
Apply  Situational  Understanding 
Evaluate  C^erational  Ehuronment 
Determine  Vulnerabilities 
Determine  Opportunities 
Develop  Strategy 
Determine  End  State 
Develop  ^sumptions 
Develop  Objectives 
Develop  Courses  oF  Action 
fesess  Available  Capabilities 
Understand  Objectives 
Develop  Options 
Analyse  Course  oF  Action 
Establish  Selection  Criteria 
Evaluate  Courses  oF  Actions 


>  U.S.  DoD  authoritative 
management  construct  for 
partitioning  military  capabilities 

>  Provides  taxonomy  and  vocabulary 
for  defining  C2  from  a  process 
perspective 

>  Tier  1  JCA’s  may  be  considered  an 
intermediate  ontology-like  construct 
that  relates  C2  to  the  larger  DoD 
capability  domain 
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Vocabulary  and 


Model 


Emerging  U.S.  DoD  approach  to 
facilitate  understandable  and 
interoperable  C2  data  sharing 


Includes  a  conceptual  model  and 
vocabulary  for  commonly 
exchanged  C2  data 


>  Extended  from  the  U.S.  Universal 
Core  [5] [44],  which  may  be 
considered  an  intermediate 
ontology-like  construct 


constn 
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Consultation  Command  and  Control 
InfoiHation  Exchange  Data  Model  (JC3I1BM) 
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(MSG) 
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>  Doctrinally  based,  comprehensive 
product  based  on  ~  20  years  of  C2 
domain  expert  inputs  [46][47] 


Relevant  artifacts  include 
conceptual  and  logical  data  models, 
extensive  vocabulary,  and  rules  set 

Numerous  papers  exploring 
relevance  of  JC3IEDM  to  a  C2 
domain  ontology  (ICCRTS,  SISO), 


COI  and  Program  Vocabularies 


Community  of  Interest  Activities 


Promote  Visibility 


Promote  Understandability 


Promote  Accessibility 


Define  data  sharing  shortfall  as  a 
problem  statement 

Define  COI-specific  vocabularies  and 
taxonomies 

Register  semantic  and  structural 
metadata  to  the  DoD  Metadata  Registry 

Make  data  assets  visible  and  accessible 
through  web-services 

Conduct  Pilots,  Participate  in 
Experiments  or  Exercises 

Facilitate  implementation  of  capabilities 
in  Programs  of  Record 


COI  products  include  vocabularies,  taxonomies,  metadata  (semantic, 
structural,  and  discovery),  web-services,  lessons  learned,  and 
DOTMLPF  recommendations. 


UNCLASSIFIED 


>  Numerous  C2-related  COIs 
producing  semantic  products  to 
facilitate  data  sharing  for  a  specific 
mission 

Maritime  Domain  Awareness 
Time  Sensitive  Targeting 
Joint  Air  and  Missile  Defense 
Meteorology  and  Oceanography 
Global  Force  Management 

>  Not  domain  ontologies,  but  share 
entities  with  and/or  model  part  of 
the  C2  domain 

May  also  serve  as  lower 

_ J _ I _ j  0  *  ^ _ —I _ Am 

“I 


C2  Architecture  Products 


Operational 


Framework  Product  Name 


General  Description 


Overview  and  Summary 
Information 
Integrated  Dictionary 


High-Level  Operational 
Concept  Graphic 


Operational  Node  Connectivity 
Description 

Operational  Information 
Exchange  Matrix 


Organizational  Relationships 
Chart 


Operational  Activity  Model 


Operational  Rules  Model 


Operational  State  Transition 
Description 

Operational  Event-Trace 

Description 


Logical  Data  Model 


Scope,  purpose,  intended  us^s,  environment  depicted, 
analytical  findings 

Architecture  data  repository  with  definitions  of  all  terms  used  in  | 

all  products 


High-level  graphicali'textual  description  of  operational  concept 


Operational  nodes,  connectivity,  and  information  exchange 
needlines  between  nodes 

Information  exchanged  between  nodes  and  the  relevant 
attributes  of  that  exchange 


Organizational,  role,  or  other  relationships  among 
organizations 


Capabilities,  operational  activities,  relationships  among 
activities,  inputs,  and  outputs;  overlays  can  show  cost, 
performing  nodes,  or  other  pertinent  information 


One  of  three  products  used  to  describe  operational  activity- 
identifies  business  rules  that  constrain  operation 


One  of  three  products  used  to  describe  operational  activity- 

identities  business  process  responses  to  events 

One  of  ihree  products  used  to  describe  operaiional  activity- 

traces  actions  in  a  scenario  or  sequence  of  events 


Documentation  of  the  system  data  requirements  and  structural 


U.S.  DoD,  NATO,  and  coalition 
partners  have  been  developing 
C2  operational  architectures  for 
several  years 

Architectural  artifacts  describe 
operational  entities,  relationships 
between  them,  information  that  is 
exchanged,  and  relevant 
processes.  (Ontology-like) 

Large  scale  integrated 
architecture  efforts  such  as  the 
JFCOM  JjjF  C2  architecture-jpe  ^ 
akin  to  C2  domain:model 


UJTL 


NATO  C2  Conceptual  Model  (SAS-050  w) 


■  Intent 

■  Roles 

■  Relationships 

■  Information  flows 
■ROE 

■  Resources 


Sensemaking 


Individual 
Characteristics 
&  Behaviours 


Team 

Characteristics 


Individual 
Awareness. 
Understanding, 
&  Knowledge 

Shared 
Awareness. 
Understanding, 
&  Knowledge 


r 

Quality  of 
Decisions 

Ajctions 

J 

This  Reference  Model  consists  of 
a  catalogue  of  variables  and  relationships 
that  are  thought  to  be  relevant  to  C2. 

Contains  >300  Variables  and  >3000  Relationships 


Value  View 

A  subset  of  variables  from  the 
Reference  Model  that  have 
been  selected  to  rep  resent  the 
utility  of  a  C2  Approach. 


Working  Models 

Instantiations  of  subsets  of 
variables  and  relationships  that 
represent  a  specific  C2 
Approach  and  process. 


Conceptual  model  of  C2 
intended  to  capture  knowledge 
and  serve  as  point  of  departure 
for  further  exploration 

Main  components  are 
Reference  Model,  Value  View, 
Working  C2  process  models 

Generic  process  view  of  C2 
not  specific  to  any  operational 
domain,  (an  intermediate 
ontology?) 

C2  Reference  Model  contains 
wealth  of  information  regarding 
C2  entities  an 


Ontological  IgayeriRg  of  C2  Artifacts 


Basic  Formal 
Ontology 
Occurents 


Basic  Formal 
Ontology  Continuents 


Formal 

Level 


UCore  Who,  What 
JC3IEDM  Object  Type 
C2  Architecture  Object  Types 


Intermediate 

Level 


•  Tier  1  Joint 

Capability 

Areas 


Regional 

Level 


•  Tier  2-4  C2 
Capabilities 

•  SAS-50  Working 
Models 

•Universal  Joint  C2 
Tasks 

•  Joint  C2  Mission 
Threads,  e.g.  JCAS, 
Crisis  Action 
Planning 


C2  Core,  JC3IEDM,  COI,  and  Misc  Data  Models 
SAS-50  Reference  Model  elements, 

C2  Architecture  Objects,  e.g. 

Mission 
Orders 

Personnel 

Air 

Tasking 
Order 


JF  Component 
Commanders 


Weapon 


Target 


Army 

OPORD 


JFACC 


OPORD 

BZ-02 


/ COL  Smith  preparing 
anJdPLAN 
•Torch  31  Close 
Air  Support  Mission 


COL  Smith  ATO  AB-01 
{SGT  Snuffy 
CAPTAhab 


101st  ABN 


Instance: 


Situation  at  time(f 


■ 
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v SITUATIONAL  MODEL 

USING  REFERENT  TRACKING  U 

I  I  Z ^ 

Referent  Tracking  Concept  Illustration  from  Cuesters  [58] 


Recommendations,  and 

Challenges 


Summary  and  Conclusion 


>  Ontology  has  been  used  successfully  (for 
Hhousands  olyears)  to  capture  and  represent 

domain  knowledge  aid  facilitate  practical 
understanding,  reasoning,  and  information 
integration 

>  Based  on  successes  in  the  biological  and  other 
domains,  the  authors  conclude  Ihat  development 
of  a  practical  (bun  partial)  C2  domain  ontology  is 
feasible  in  the  near  Id  mid  term 


Practical  Recommendations  for 
Realizing  a  C2  Domain  Ontology 


>  Identify  relevanf  and  feasible  applications  that 
be  achieved  in  the  near  to  mid  term 

>  Establish  a  common  approach  to  C2  ontology 
specification 


>  Adopt  the  realist  perspective 

>  Leverage  existing  C2  onlology-like  artifacts 


>  Scope,  complexity,  diversity,  and  unclear 
partitions  and  boundaries  of  C2 

>  Process-based  nature  and  strong  human 
element  of  C2 

>  Dependencies  on  other  warfighting  domains 
that  do  not  have  ontologies  in  place 

>  Time  and  resource  requirements 

>  Constantly  evolving  nature  of  warfare 
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